Jerry's Blogs

Sunday, December 16, 2007

On Consistent Development Environments

It's painfully clear how ineffective I am on other people's computers these days. There's muscle memory in my hands to do all kinds of common and not-so-common tasks. Launch an application? Alt-Esc (QuickSilver). Navigating text? Emacs key bindings. Email? Chat? Webbing? You name it, I've got some obscure keyboard sequence to go about it. I'm not the only one either, since it seems that everyone in rescomp has a very customized daily workflow. Dotfiles are pimped out to the limits of un-usuability by any foreign hands.

Now that everything's customized just so, you'd think productivity should shoot through the roof. Unfortunately, I've found this to not be the case. Once people get cozy, a whole new nightmare creeps up. Instead of people being very dependent on environments, CODE will become dependent on the environment. The code may expect certain environment variables to be set; It may expect certain libraries to be installed; It may expect to be put in a certain location in the filesystem; It may only work when just the right amount of sunlight hits it. These problems don't crop up as long as you continue to develop in the same environment as the code, but is really shortsighted and hard to maintain later on.

What solutions are there? Obviously, you can write out a ton of config files that are meticulously tailored and configured for every development and production box. But it's equally clear that this can get hairy and different combinations will eventually lead to deprecated configs and major rewrites. The other approach is to centralize as many things together and minimize the different places configurations can be made. I see this as a much better practice for maintaining consistent development environments. Instead of writing documentation that tells new developers the dependencies they need to install in order to build the app, simply bundle the dependencies along with the app. Similarly, when developers use 3rd party libraries, why not version it alongside the app code to maintain a _single_ consistent version of the library that all developers share? Taking this philosophy to the extremes, we can even apply this to deployment and production. Bundle the toolchain, OS, servers, hardware, and support software... Imagine how fantastic it would be to pull a VM from the net and be confident that a bug is a real bug, and not a bad configuration.

Oh, and zombies scare the crap out of me, especially when seen in IMAX form

Labels: ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home